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TO WHOM IT MAY CONCERN: 

Be it know that WE, EDWARD J. HOGAN and CARL M. CAMPBELL, both 
citizens of the UNITED STATES OF AMERICA, residing in LARCHMONT, County of 
WESTCHESTER, State of NEW YORK and NEWTOWN SQUARE, County of DELAWARE, 
State of PENNSYLVANIA, whose post office addresses are 14 N. CHATWORTH AVENUE, 
LARCHMONT, NEW YORK 10538, and 809 MALIN ROAD, NEWTOWN SQUARE, 
PENNSYLVANIA 19073, respectively, have invented an improvement in 

AN IMPROVED METHOD AND SYSTEM FOR CONDUCTING 
SECURE PAYMENTS OVER A COMPUTER NETWORK 

of which the following is a 

SPECIFICATION 
PRIORITY A PPLICATIONS 
[0001 ] This application claims priority to United States provisional application 

60/195,963, filed on April 11, 2000, and entitled "Method and System for Conducting Secure 
Payments Over A Computer Network," which is hereby incorporated by reference, and to United 
States application serial number 09/809,367, filed March 15, 2001, and entitled "Method and 
System for Secure Payments Over A Computer Network," also incorporated by reference. 
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BACKGROUND OF INVENTION 

[0002] This invention relates to a method and system for conducting secure financial 

transactions over a communications network and more particularly to a method and system for 
transmitting payments securely over a computer network, such as the Internet, and for 
transmitting sensitive information securely over public communication channels. 

[0003] As is self-evident, on-line commerce has experienced tremendous growth over the 

last few years but even with that growth consumers are still troubled and concerned about using 
personal financial information and transmitting such information, such as credit card numbers 
and personal identification numbers, over public communications networks, such as the Internet. 
As a result, over the last few years, companies have struggled to find a way - the best way - to 
ensure the security of payments made over a computer network and to decrease the risk of theft 
or misuse of financial information. 

[0004] For example, U.S. Patent No. 5,883,8 10 entitled "Electronic Online Commerce 

Card With Transaction Proxy Number For Online Transactions" and assigned to Microsoft 
Corporation, is directed to a system which provides for each transaction a temporary transaction 
number and associates it with the permanent account number; the transaction number looks like a 
real credit card number and the customer uses that transaction number and submits it to the 
merchant as a proxy for the customer account number. In this matter, the customer does not 
have to transmit over a public network his or her real credit card number. 

[0005] In the '810 patent, the merchant passes along the transaction number to the 

issuing institution, which in turn uses the transaction number as an index, accesses the real 
customer account number and processes the authorization, sending the authorization reply back 
to the merchant under the transaction number. As a result, risk is purportedly minimized not 
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only because the customer only transmits a transaction number but also because the proxy 
number is good only for a single purchase - theft "would not greatly benefit a thief because it 
cannot be repeatedly used for other purchases or transactions." Col. 2, lines 60-61. 

[0006] There is a need to improve upon the prior art systems and in particular there is a 

need for a method and system for conducting a secure financial transaction over the Internet 
which avoids requiring the creation and transmission of a unique repeatedly generated 
transaction number to replace the transmission of the permanent account number for each 
conducted transaction. 

[0007] According to the invention of co-pending application 09/809,367, filed March 1 5, 

2001, which is incorporated herein by reference, a "pseudo" account number is assigned to a 
customer and cryptographically linked to a consumer's payment account number. The payment 
account number is an account number issued by a financial institution or other organization that 
a consumer may use to make a payment for goods and/or services. For example, the payment 
account number may be the account number from a payment card, such as a credit or debit card, 
or from a payment application, such as an electronic cash application stored on a consumer's 
computer. The pseudo account number appears to be an actual payment account number to a 
merchant. That is, the pseudo account number has the same length as a valid payment account 
number and begins with a valid identification number (e.g., a "5" for MasterCard International 
Incorporated ("MasterCard")). The pseudo account number is used by the customer instead of 
the real account number for all of his or her on-line financial transactions. 

[0008] According to the invention of the co-pending application 09/809,367, all 

transactions based on pseudo account numbers are preferably cryptographically authenticated 
using a secret key that is unique for each account number. The authentication may be based on 
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the private key of a public-key pair ("public-key authentication 9 '), or based on a secret key other 
than a private key ("secret-key authentication"). Thus, if unauthorized persons were to ascertain 
any pseudo account numbers, they would be unable to make fraudulent transactions using them. 

[00091 This system can still be improved upon and security can be further enhanced to 

protect the messages and information being transmitted during or in connection with a financial 
transaction being conducted over public communications lines. 

SUMMARY OF INVENTION 

[0010] According to the present invention, therefore, a method of conducting a 

transaction using a payment network is provided, in which a service provider receives a first 
authorization request for the authorization of a transaction using a first payment account number, 
wherein: 

(i) the first payment account number has a BIN code 
associated with the service provider, and is associated with a 
second payment account number having a BIN code associated 
with an issuer of said second number; 

(ii) the first authorization request includes an acquirer code 
associated with an acquirer; and 

(iii) the first authorization request is routable through the 
payment network to the service provider based on the BIN code of 
the first payment account number. 

[0011] The method further includes having the service provider respond to the first 

authorization request by transmitting a second authorization request for authorization of the 
transaction using the second payment account number, the second authorization request 
including an acquirer code associated with the service provider and being routable through the 
payment network to the issuer based on the BIN code of the second payment account number. 
[0012] Additionally, a response to the second authorization request is received by the 

service provider from the issuer, where the response includes the acquirer code associated with 
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the service provider and is routable through the payment network based on that code. A 
response to the first authorization request is then transmitted by the service provider to the 
acquirer based on the response to the second authorization request, and the response to the first 
authorization request preferably includes the acquirer code associated with the acquirer and is 
routable through the payment network based on that code. 

[0013] Another preferred embodiment of the invention includes a method of conducting 

a transaction with a merchant using a first payment account number that is associated with a 
second payment account number, where the method comprises: (a) generating a message 
authentication code based on one or more transaction details; (b) transmitting at least the first 
payment account number and the message authentication code to the merchant; (c) requesting by 
the merchant an authorization for payment of the transaction using the first payment account 
number, the request being formatted as if payment were tendered at a point-of-sale terminal with 
a conventional magnetic-stripe payment card, the message authentication code being transmitted 
in a discretionary data field contained in a track of the type used in the magnetic stripe of said 
conventional payment card; (d) responding to the authorization request for the first payment 
account number by requesting an authorization for payment of the transaction using the 
associated second payment account number; and (e) accepting or declining the authorization 
request for the first payment account number based on the response to the authorization request 
for the second payment account number and the message authentication code. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] Further objects, features and advantages of the invention will become apparent 

from the following detailed description taken in conjunction with the accompanying figures 
showing a preferred embodiment of the invention, on which: 
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[0015] FIG. 1 is a block diagram of the system for obtaining a secure payment 

application from a provider over the Internet in accordance with the invention; 

[0016] FIG. 2 is a flow diagram illustrating the flow of information between a cardholder 

and a merchant when conducting a secure payment over the Internet using the present invention; 

[0017] FIG. 3 is a flow diagram illustrating the flow of information between an acquirer, 

a service provider and an issuer, in accordance with the present invention; 

[0018] FIG. 4 is a flow diagram illustrating the flow of information between an issuer, a 

service provider and an acquirer, in accordance with the present invention; 

[0019] FIG. 5 is a flow diagram illustrating the flow of communication between a 

merchant and an acquirer for purposes of settlement and clearing, in accordance with the present 
invention; 

[0020] Throughout the figures, the same reference numerals and characters, unless 

otherwise stated, are used to denote like features, elements, components or portions of the 
illustrated embodiment. Moreover, while the subject invention will now be described in detail 
with reference to the figures, it is done so in connection with a preferred embodiment. It is 
intended that changes and modifications can be made to the described embodiment without 
departing from the true scope and spirit of the subject invention as defined by the appended 
claims. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Initialization of the Secure Payment Application 

[0021] In accordance with a preferred embodiment of the invention, a service provider 

issues, maintains and/or processes several components, including a secure payment application 
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("SPA"), of the secure payment system to be conducted in accordance with the techniques of the 
present invention. 

[0022] Figure 1 illustrates first how a cardholder with a financial transaction card may 

obtain a secure payment application from the service provider 10 over the Internet, according to 
an exemplary embodiment of the present invention. It should initially be understood that a 
physical card is not necessary to utilize and obtain the benefits of the invention, but that only an 
account number be issued to a holder (in this case a cardholder) which identifies and links a user 
or participant to an account for purposes of conducting a financial transaction. The cardholder 
may contact a web server associated with the service provider using any appropriate device that 
may communicate over the Internet, such as a computer, cellular phone, or a personal digital 
assistant (PDA). For the purpose of simplicity in the following discussions, it is assumed that the 
cardholder uses a computer to communicate over the Internet. 

[0023] As shown in Fig. 1 , the service provider, for example MasterCard International 

Incorporated (or an agent of MasterCard), has in its control one or more physically secure 
security modules 12, which offer physical protection for the information stored inside the 
modules. These security modules each contain one or more "derivation keys" that are used to 
create and re-create account-unique secret cryptographic keys, as explained below, which are 
provided within the secure payment application. 

[0024] First, in accordance with a preferred embodiment of the invention, the cardholder 

must obtain an SPA from the service provider. The preferable steps for downloading and 
initializing the secure payment application (SPA) include: 

1 . The cardholder contacts the service provider's web site via the Internet (either directly or 
through a hyperlink to the web site through another web site, such as an issuer's web site. 
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2. The cardholder provides, under SSL encryption generally known to those skilled in the 
art, (a) a payment card account number, (b) a card expiration date, and (c) card 
authenticating information. The card authenticating information may include, for 
example, the card's CVC2 value, which refers to a three or four digit value that is printed 
next to the signature panel of some cards. This value is generated by the issuing bank 
using a secret cryptographic key and can be verified using this same key. 

3. The service provider may confirm the legitimacy of the card account number and the card 
expiration date by obtaining a zero amount authorization from the issuer of the 
cardholder's payment card. For instance, MasterCard may obtain this authorization over 
its Banknet™ communications network. 

4. The service provider may verify the CVC2 value if the issuer of the cardholder's payment 
card has provided the service provider with the cryptographic key(s) for verifying the 
CVC2 value. 

5. The service provider may verify other card authenticating information by sending such 
information to the issuer for verification. 

6. After the service provider ("SP") has confirmed the legitimacy of the cardholder- 
provided card data, the SP creates or selects a pseudo account number and a secret key 
and embeds these data elements into a secure payment software application that is made 
available to the cardholder for download over the Internet preferably under SSL 
encryption. 

[0025] The pseudo account number has as its BIN a special BIN reserved for pseudo 

account numbers. The remainder of the pseudo account number is a value that can be translated 
by the service provider via a table look-up process to the "real" account number. 
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[0026] Preferably, the assigned special service provider BIN may be one from a set of 

many such special BINs, where each BIN may correspond to a particular country or region 
and/or to a particular product within a country or region. Thus, the assigned special BIN may be 
the one that corresponds to the country and/or the product of the submitted "real" account 
number. 

[0027] The secret key that the service provides preferably embeds in an SPA is unique 

for each card account number and is preferably derived within a security module using the card 
account number and a derivation key. This derivation key may itself be derived within the same 
or another security module using a higher-level derivation key. 

[0028] The cardholder may provide a password to the service provider prior to 

downloading the secure payment application or may select a password when the secure payment 
application is being installed on the cardholder* s computer. If a password is provided or selected, 
the cardholder will thereafter be required to enter this password in order to activate the secure 
payment application. The password selected by the cardholder may be used to encrypt the secret 
key included in the SPA. 

[0029] As would be recognized by those skilled in the art, the SPA may be downloaded 

as part of a digital wallet application. In addition to the SPA, the digital wallet may store a 
cardholder's personal information and other applications, such as a purse application. 

Generating Card-Unique Secret Keys 

[0030] The following steps may preferably be performed within a security module 12 

controlled by the service provider or one of its agents to obtain a card-unique secret key to be 
included in the secure payment application. The following steps assume that the cardholder's 
payment card has a 16-digit account number and that the Data Encryption Algorithm (DEA) 
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known to those skilled in the art, with a double-length key is used. The DEA is a U.S. 
Government standard cryptographic algorithm that is described in Federal Information 
Processing Standard (FIPS) 46-1, which is incorporated herein by reference in its entirety. The 
DEA is also defined in the ANSI standard X9.32, which is also incorporated herein by reference 
in its entirety. 

[0031] It is also assumed that the security module holds a secret high-level key called the 

derivation key that consists of 16 bytes and is used with many or all card account numbers to 
cryptographically compute a card-unique secret key, called the Per-Card Key, given the 
cardholder's 16-digit payment account number. The derivation key may be unique for each 
country or for each special bank identification number or BIN. 

[0032] Preferably, the steps are: 

1 . Considering the payment account number as 16 binary-coded-decimal digits of 4 bits 
each, DEA-encrypt these 64 bits using as the encryption key the left-most 8 bytes of the 
16-byte Derivation Key. 

2. DEA-decrypt the result of Step 1 using as the decryption key the right-most 8 bytes of the 
16-byte Derivation Key. 

3. DEA-encrypt the result of Step 2 using as the encryption key (again) the left-most 8 bytes 
of the 1 6-byte Derivation Key. 

4. Use the result of Step 3 as the left-most 8 bytes of the unique Per-Card Key. 

5. DEA-encrypt the result of Step 3 using as the encryption key the left-most 8 bytes of the 
16-byte Derivation Key. 
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6. DEA-decrypt the result of Step 5 using as the decryption key the right-most 8 bytes of the 
16-byte Derivation Key. 

7. DEA-encrypt the result of Step 6 using as the encryption key (again) the left-most 8 bytes 
of the 16-byte Derivation Key. 

8. Use the result of Step 7 as the right-most 8 bytes of the 16-byte unique Per-Card Key, and 
place this key in the secure payment application in such a way that it will not be disclosed 
during the normal operation of this application. 

Communication Between C ardholder and Merchant 

[0033] Fig. 2 illustrates the flow of information between the cardholder 14 and merchant 

16 when conducting a secure payment over the Internet according to an exemplary embodiment 
of the present invention. 

[0034] Once the SPA has been installed on a cardholder's computer, the cardholder 

preferably uses the SPA for all Internet payments and the SPA provides the cardholder's pseudo 
account number for all Internet transactions. 

[0035] Once a cardholder has indicated a desire to conduct a transaction, it is desirable 

(but not essential) that the merchant pass to the cardholder's computer the following data 
elements: (1) the acquirer BIN, (2) the MID (the merchant identifier as known to the acquirer), 
and (3) the date and time (GMT or equivalent) of the transaction. 

[0036] Preferably, the SPA uses its embedded, secret key to create a Message 

Authentication Code (MAC) relating to the transaction. For example, a MAC of approximately 
8 decimal digits may be created on the following data elements: 
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1 . A transaction sequence number stored in the cardholder's SPA and incremented by the 
SPA whenever it generates a MAC. This transaction sequence number may be, for 
example, six (6) decimal-digits in length. 

2. The acquirer BIN if received from the merchant, otherwise zeros (which may be, for 
example, 6 decimal digits). 

3. The MID if received from the merchant, otherwise zeros (which may be, for example, 6 
decimal digits). 

4. Date and time, to the nearest hour or minute (in GMT), if received from the merchant, 
otherwise zeros (which may be, for example, 10 decimal digits). 

5. The transaction amount, as displayed for the cardholder, and as normally included in the 
message from cardholder to merchant (which may be, for example, 8 decimal digits). 

[0037] Preferably, a merchant is able to accept a full Track- 1 image from the 

cardholder's computer, just as if the merchant were prepared to communicate with computers 
that include magnetic-stripe readers. (The Track- 1 image refers to the data on track 1 of the 
magnetic stripe of a payment card.) Moreover, the merchant preferably is able to pass the Track- 
1 data to the acquirer as if the transaction were a point-of-sale (POS) transaction. 

[0038] If the merchant can accept the full Track- 1 data, the MAC itself and the data 

elements upon which the MAC is based are placed in the Track- 1 discretionary-data field. The 
pseudo account number is placed in the Track- 1 account-number field, and the card expiration 
date is placed in the Track- 1 expiration-date field. 

[0039] By sending the MAC in the Track- 1 discretionary-data field, many merchants will 

not need to make any changes to their systems and/or software because they can already handle 
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POS transactions, which include Track- 1 discretionary data. For other merchants, systems 
and/or software to handle POS transactions are readily available. 

[0040] If a merchant cannot accept the full Track- 1 data, the SPA may send a 

conventional SSL payment message, except that the pseudo account number is used instead of 
the cardholder's "real" account number. The merchant then sends the transaction data to the 
acquirer in the manner that it normally does. In practice, during a transition period, the 
merchants that are not capable of handling POS transactions with Track- 1 data might not be 
required to receive and handle MACs. 

[0041] Instead of being sent in the Track- 1 discretionary-data field, the MAC may also 

be sent in another format, in which case merchants and acquirers may be required to change their 
systems and/or software to handle this other format. 

[0042] Upon receipt of the cardholder's transaction message, the merchant formats a 

conventional authorization request for the acquirer. For those merchants that are able to able to 
accept Track- 1 data, this authorization request will be formatted exactly as if it originated from a 
POS terminal and will include the Track-1 data provided by the cardholder. 

[0043] Should a merchant initiate multiple authorization/clearing transactions for a 

cardholder transaction, preferably only the first of these transactions will include the Track-1 
data. The subsequent transactions will include only the pseudo account number and expiration 
date and may be considered mail-order-telephone-order transactions. This is true for all 
recurring payments and partial payments with multiple clearings. 

Acquirer Handling of Authorization Request 

[0044] Fig. 3 illustrates the communication between an acquirer 18, service provider 10, 

and an issuer according to an exemplary embodiment of the present invention. 
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[0045] The presence of Track- 1 data in an Internet transaction should not adversely 

impact those acquirers who receive transactions from Internet merchants via conventional 
telephone lines, since such transactions will be formatted identically to transactions from 
conventional point-of-sale terminals. However, acquirers who receive transactions via the 
Internet (and not conventional telephone) may need a "conversion box" that would deliver 
transactions without Track- 1 data unchanged and would deliver transactions with Track- 1 data 
over a different physical wire as if they had come from POS terminals. The design of such a 
conversion box is well within the ability of a person of ordinary skill in the art. 

[0046] When an acquirer 18 receives an authorization request message from an Internet 

merchant 16, it looks up the issuer BIN in its BIN table. In the case of a pseudo account number 
transaction, the "issuer" will correspond to a service provider-authorized processing facility 10, 
which will receive the request. In the case of a non-pseudo or real account number, normal 
processing will take place. 

[0047] Some countries may have a special security-module-equipped facility that handles 

domestic transactions. Each such domestic facility would preferably be set up only with the 
service provider's approval and would hold only the cryptographic keys and account-number 
conversion data for the country whose transactions it processes. In countries with such a 
domestic facility, all same-country transactions will be sent to this facility. This can also be done 
for individual banks in a country, if it is so desired. 

[0048] A domestic facility to handle domestic transactions would be far more efficient 

than causing domestic transactions to go through a central processing facility. 
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Service Provider Handling o f the Authorization Request 

[0049] When the service provider receives the request, it determines from the issuer BIN 

whether the account number is really a pseudo account number and, if so, sends the transaction 
to a special system for processing. This system translates the pseudo account number to the 
"real" account number using a table-lookup procedure. If the system determines that a Track- 1 
image is included, it uses a security module to derive the appropriate Per Card Key for this card 
account number in order to verify the MAC. (The derivation of the Per Card Key is described 
above.) 

[0050] If the MAC is verified, the system then examines the BIN in the Track- 1 

discretionary-data area. If this is not all zeros, the system compares this BIN with the acquirer 
BIN of the transaction, and verifies that the date and time included in the Track-1 discretionary- 
data area are reasonable (taking into consideration that the merchant may batch its transactions 
and obtain delayed authorizations). The system also verifies that the authorization request 
amount does not exceed the transaction amount in the Track-1 discretionary-data area (the 
amount as approved by the cardholder) by more than a specified amount (e.g., 20%). 

[0051] It is possible that an acquirer may include the MID in the Acquirer Reference 

Data (which is also called the Acquirer Reference Number). It is assumed that the 23-digit 
Acquirer Reference Data includes a mandatory "transaction type" indicator and a mandatory 
acquirer BIN, but that the remaining digits are for the acquirer's discretionary use and may in 
some cases include the MID. The service provider may obtain from its Internet acquirers an 
indication of which acquirers include the MID in the Acquirer Reference Data, and if so, where 
in the Acquirer Reference Data they include it. In the case of such an acquirer, if the Track-1 
image includes an acquirer BIN (rather than six zeros), the service provider system may also 
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verify that the MID in the Track- 1 discretionary-data area matches the MID in the Acquirer 
Reference Data. 

[0052] The service provider system may store a history of transaction sequence numbers 

(TSNs) for comparison with transaction sequence numbers in authorization requests. The 
comparison may be triggered by some condition, such as when the Track- 1 amount exceeds 
some specified threshold (e.g., $200). Such a threshold may be lower when the Track-1 image 
does not include an acquirer BIN. When the comparison is triggered, the system may compare 
the transaction sequence number included in the Track-1 discretionary-data area against the 
stored history of transaction sequence numbers for the relevant card account number. If the 
transaction sequence number of the current transaction is 1) higher than the smallest stored value 
for the current account number and 2) does not match any stored value for this account, there is a 
reasonable assurance that the current transaction is not the fraudulent replay of data from a 
previous legitimate transaction. 

[0053] The stored history of TSNs may be limited to a predetermined number of TSNs. 

For example, the system might store only the last 10 transaction sequence numbers received for a 
particular card account number. In addition, the verification of transaction sequence numbers 
need not occur in real time. It may occur while the system is obtaining an authorization from an 
issuer. 

[0054] The purpose of these checks is to make it very difficult for wrongdoers who 

operate in collusion with Internet merchants and who may be able to obtain unencrypted 
transaction data to fraudulently replay data from legitimate transactions. 

[0055] Once the service provider system has completed the above-described verification 

processes (with the possible exception of the transaction sequence number verification), the 
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system formats an authorization request message for the issuer 20. This message includes the 
"real" account number and expiration date, but excludes the other Track- 1 data. The system 
replaces the acquirer BIN with one of the special BINs that serves as a "pseudo" acquirer BIN. 
The acquirer BIN is replaced so that the issuer responds to the service provider instead of the 
acquirer. 

[0056] In order for the acquirer and issuer to compute interchange fees correctly, the 

pseudo acquirer BIN should preferably correspond to the country in which the acquirer is located 
or to another country or region that will provide the same resultant interchange fees. If each 
country has a special BIN associated with it, the service provider may replace the acquirer BIN 
with the special BIN associated with the acquirer's country. If an acquirer's country does not 
have a special BIN associated with it, a special BIN associated with another country may be 
selected that results in the same interchange fees. 

[0057] The service provider stores in a database the Acquirer Reference Data received in 

the authorization request from the acquirer (hereinafter referred to as the "original Acquirer 
Reference Data"). In formatting an authorization message for the issuer, the service provider 
preferably replaces the original Acquirer Reference Data with "pseudo" Acquirer Reference Data 
that includes the pseudo acquirer BIN, an appropriate transaction-type indicator, and an index 
value that the service provider can use to find the original Acquirer Reference Data. 

[0058] When a domestic facility processes a pseudo-account-number transaction, it 

operates as described above. Preferably, however, this domestic facility will process only 
transactions for domestic issuers, and therefore will need only the cryptographic keys and 
account-number conversion table entries that apply to that country. 
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Issuer Handling Of Authorization Request 

[0059] Fig. 4 illustrates the communication between the issuer 20, the service provider 

10, and an acquirer 18 according to an exemplary embodiment of the present invention after the 
issuer has received an authorization request from the service provider or from an authorized 
domestic processing facility. 

[0060] The issuer 20 authorizes the transaction just as it would any other transaction. It 

sends the authorization response back to the "pseudo" acquirer BIN, which will be either a 
service provider facility or a facility authorized by a service provider. 

[0061] When the service provider 10 receives an authorization response from an issuer, it 

examines the acquirer BIN to determine whether it is a "pseudo" acquirer BIN. If so, the service 
provider determines that the authorization response corresponds to a pseudo account number 
transaction that must be "restored" to its original format. Thus, the service provider translates 
the "real" account number back to the pseudo account number, and restores the Acquirer 
Reference Data that had been in the original transaction. The service provider then transmits the 
resulting message to the "real" acquirer, which processes the transaction normally and sends the 
authorization response to the merchant in the normal way. The merchant responds to the 
authorization response as it would for any other transaction. 

Settlement and Clearing 

[0062] Figure 5 illustrates the flow of communication between a merchant 16, an 

acquirer, service provider or payment processor, for example, MasterCard's Banknet, and an 
issuer for the purpose of settlement and clearing according to an exemplary embodiment of the 
present invention. 
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[0063] A clearing message is processed essentially in the same manner as an 

authorization request message. As previously described, the acquirer 18 (because of entries in its 
BIN table) automatically routes a clearing message using a pseudo account number preferably to 
the service provider 10 or payment processor At this facility, the pseudo account number is 
replaced by the "real" account number, the acquirer BIN is replaced by the "pseudo" acquirer 
BIN, and the remainder of the Acquirer Reference Data is replaced by an index that the service 
provider can subsequently use to obtain the original Acquirer Reference Data. The clearing 
message with these changes is transmitted to the "real" card issuer 20, which processes the 
transaction in the normal way. If the acquirer happens to also be the issuer, the service provider 
returns the cleared transaction to the acquirer with the real account number and proper fee 
calculations. 

Exception Processing 

[0064] When a message about a transaction must be transmitted back to the acquirer or 

merchant from an issuer, the message is processed by the issuer as it normally would process any 
transaction message. Since the transaction as known to the issuer includes the "pseudo" acquirer 
BIN, the "pseudo" acquirer BIN will cause the transaction message to be routed to a service 
provider facility. At this facility the "real" account number is replaced by the pseudo account 
number, and the pseudo Acquirer Reference Data is replaced with the original Acquirer 
Reference Data. The transaction message is then routed to the acquirer, which processes it like 
any other such transaction message. 
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Issuance of Plastic Cards for Identification 

[0065] In some situations, a cardholder may buy a ticket over the Internet and will be 

required, upon showing up at the event to which the ticket grants admission, to produce the card 
used in the transaction in order to authenticate rightful possession of the ticket. 

[0066] To accommodate such situations, the service provider may issue and mail 

physical plastic cards to cardholders who obtain pseudo account numbers for Internet use. These 
cards would clearly indicate "for identification purposes only, not valid for transactions" on 
them. The embossed and encoded account number would be the pseudo account number, though 
the CVC2 may be that of the "real" payment card. 

[0067] As another alternative, those merchants that have a legitimate need to authenticate 

a cardholder using a pseudo account number may register with the service provider (by providing 
to the service provider appropriate identification and authentication information), and the 
merchants will be provided with a secret key or certificate as cryptographic proof of their 
registration. Thereafter, such merchants may obtain "real" account numbers from a service 
provider facility by providing a copy of the pseudo-account-number transaction details under 
cryptographic authentication that authenticates both the transaction data and the merchants 5 right 
to obtain a "real" account number. The service provider may then forward the "real" account 
numbers in encrypted form to the merchants, so that the cardholders may be identified with the 
cards corresponding to their "real" account numbers. 

[0068] Advantageously, the present invention provides enhanced security for the use of 

payment account numbers over the Internet. 

[0069] The foregoing merely illustrates the principles of the invention. It will thus be 

appreciated that those skilled in the art will be able to devise numerous systems and methods 
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which, although not explicitly shown or described herein, embody the principles of the invention 
and thus within the spirit and scope of the invention. 
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